Generally speaking, such networks enable sessions to be set up, each one between a source unit and a destination unit, interconnected via one or more network nodes. During each session, the destination unit and/or one or more network nodes carry out transmission and/or service operations. The destination unit and/or the node(s) carrying out the aforementioned operations are used by a network operator and/or a service provider. In the present description, by service provider is hereby also understood a content provider.
By transmission operations are understood data packet transport operations on the network. By service operations are understood every kind of operation related to the container and content of the transmitted data packets. Service operations consist for example of an encryption/decryption of the data contained in the packets, or again of an execution of an executable or interpretable code of a program or program part contained in the packets.
Transmission and/or service operations allow for example audio or video works to be broadcast over the Internet network. In this case, a customer (the source unit, for example) sends to a service provider (the destination unit, for example) a request concerning a given work, and in return the service provider returns to the customer an audio or video data file relating to the given work.
More exactly, the invention concerns the payment (also called the “billing”) for these transmission and/or service operations.
In the interests of simplification, the following discussion is mostly concerned with the Internet. It is clear however that the invention is not restricted to this particular type of network and applies more particularly to any type of data packet transmission network.
As explained in detail in patent document WO 9733404 (LELEU), the text of which is inserted here for reference, it seems difficult, if not impossible, to implement conventional payment technologies on the Internet network for operations carried out on the networks. Indeed, the Internet network does not have the centralised administration necessary to implement these conventional payment technologies, which mainly consist of billing as a function either of the length of connection between units (for a pre-set data transmission speed and distance), or of the amount of data exchanged between two units (taking into account the data transmission speed).
For this reason, the current technology of paying for operations carried out on the Internet network consists in billing only for access at a physical point-on the network. As shown in the aforementioned patent document, this billing is either at a flat-rate, or it takes into account the amount of data sent to the whole network, or else the totality of the data received from the totality of the network.
Unfortunately, this current payment technology does not allow fair and equitable billing of transmission and/or service operations carried out within the Internet network. Indeed, currently, the billing of transmission and/or service operations is not a function of the path traversed by and of the transmission speed of the data packets.
Therefore, in patent document WO 9733404 (LELEU), a new technology has been proposed, called “token technology” in the remainder of the description. It is based on the insertion of payment tokens in the packet stream, and allowing each data packet conveyed by the network to settle for itself the cost of a transmission operation relating to its own transport, or the cost of a service operation relating to its own container or content.
The general design of this token technology will now be summarised briefly, in relation to FIGS. 1 and 2. The data packet transmission network is for example the Internet network 4. The source unit S (and/or at least one node, called a credit node) includes a packet 1 send module ME and a credit gateway PC. This latter PC assigns to each sent data packet 1 a payment token 2 which has an initial value representing a credit in monetary units previously acquired (20) from a centralising monetary agency (or “Toll Center”) 3. Each packet 1 is therefore sent (30) with the payment token 2 which is assigned to it. The destination unit D (and/or at least one node, called a debit node, located downstream of said at least one credit node) includes a packet 1 receive module MR and a debit gateway PD. The latter receives the token assigned to each packet received 1 and modifies it (40) so as to reduce its initial value by an amount representing the cost of the operations to be carried out, for the packet received 1, by the destination unit D (and/or said at least one debit node). Lastly, the destination unit D (and/or each debit node), in which is included a said debit gateway PD, requests from (50) and receives from (60) the toll center 3, for each packet 1 received during the session, financial settlement of the representative amount.
In the remainder of the description, the modification (30) of the payment token by reduction of its initial value, is sometimes also called, more simply, “payment token collection”.
In the example shown in FIGS. 1 and 2, only the source unit S includes a credit gateway PC and only the destination unit D includes a debit gateway PD. It is clear however that, in a general way, one or more credit nodes may also (or alternatively) include a credit gateway PC and one or more debit nodes may also (or alternatively) include a debit gateway PD.
In a particular embodiment of this token technology, the source unit is used by an access provider (or ISP, for “Internet Service Provider”, or again IAP, for “Internet Access Provider”), so that subscribers to this access provider may access the data packet transmission network. Thus, the credit gateway, which is implemented at the access provider, assigns tokens to the packets (i.e. inserts tokens in the IP streams) of customers accessing some service or other offered by a service provider. A service is for example recognised by its IP address and its port number (the latter identifying to which higher level protocol the request is to be passed). Conventionally, subscribers are connected to their access provider by (at least) one other communication network, such as the switched telephone network (“fixed network”, STN) or again a radio-communication network (“mobile network”, for example according to the GSM standard).
This token technology has numerous advantages. In particular it allows fair and equitable billing of transmission and/or service operations carried out within a data packet transmission network, for example of the Internet type. It may also constitute an electronic payment means, associated with the content of the packets, in the network nodes. Indeed, the payment token assigned to each data packet makes it possible to finance any type of operation (transport and/or service) carried out by the destination unit or any network node in the which the packet will reside.
However, the token technology has the major drawback of not covering the situation, which is however increasingly frequent, whereby use is made of a cache unit located, within the network, between the unit including the credit gateway (source unit or credit node) and the unit including the debit gateway (destination unit or debit node).
It will be remembered that, conventionally, a cache unit (also called a cache node) stores responses (Web pages, in the case of the Internet) to the most frequent requests to different end sites. Thus, when it receives a request for which it has previously stored the response, the cache unit itself sends the response to the customer sending said request. In this way the number of requests actually passed on to the end sites is restricted, and response times are therefore reduced. Typically, the cache unit is a “Proxy” server.
Token technology makes no provision however in the situation where a cache unit carries out one or more operations on behalf of another unit (destination unit or debit node) located downstream. This means that the debit gateway included in this other unit never receives some data packets (corresponding to requests not passed on to the end sites), and especially does not receive the payment tokens assigned to the latter. In other words, it is impossible at the present time to apply token technology when a cache unit is used.